The present invention relates, in general, to software programming systems and methods, and more specifically, to methods and apparatus for creating and testing object-oriented components with visual programming systems.
Software is increasingly becoming a major portion of cost associated with computer systems because it is very xe2x80x9clabor-intensive.xe2x80x9d Some of this cost is due to the effort involved in writing and debugging programs, other costs involve maintaining programs after they have been written. Accordingly, considerable effort has been expended in order to reduce the time and costs involved with writing, debugging and maintaining moderate and large software programs. Much of this effort has been related to developing programming languages and programming techniques which will allow programmers to build on or xe2x80x9creusexe2x80x9d programs and code segments that have been written by others.
Until very recently, software programming was heavily dominated by an approach referred to as xe2x80x9cstructured programming.xe2x80x9d Common software programming languages used in this approach were, and remain, BASIC, FORTRAN, and PASCAL. These are considered xe2x80x9chigher orderxe2x80x9d languages that are written in human readable code and ultimately translated into machine or computer readable code by a compiler. Typically, structured programs have consisted of a combination of defined variables of specific data types, e.g. integer, real, and character, and a complimentary set of functions or routines which operate on these variables. Often, a program would include sub-routines which are smaller routines within a program or larger routine that carry out certain operations, e.g. printing data in a given output format. The emphasis to this approach was inputsxe2x80x94functionsxe2x80x94outputs and they were often represented as flowcharts by the designers, which logically represented how the program functioned and branched into different functional paths. As an increasing number of programs became large (tens of thousands of lines of code and above) structured programs became increasingly complex and difficult to write, troubleshoot and maintain.
Flowcharts became unwieldy and the tracking of errors through permutations of variables, lengthy code, and a wide variety of program branches was time and cost intensive and often produced less than adequate results. Consequently, a new approach to software programming called Object-Oriented Design (OOD) or Object-Oriented Programming (OOP) emerged and has gained increasing popularity among software developers. OOP promised greater reuse and maintainability than its structured programming predecessor because of an emphasis on well-defined and self contained objects, rather than the structured programming emphasis on a proliferation of relatively loosely-related data manipulating functions and subroutines.
Object Oriented Programming techniques involve the definition, creation, use and destruction of xe2x80x9cobjects.xe2x80x9d These objects are software entities comprising data elements, or attributes, and methods, or functions, which manipulate the data elements. The attributes and related methods are treated by the software as an entity and can be created, used and destroyed as if they were a single item. Together, the attributes and methods enable objects to model virtually any real-world entity in terms of the entity""s characteristics, represented by the data elements, and the entity""s behavior, represented by data manipulation functions or methods. In this way, objects can model concrete things like people and computers, and they can also model abstract concepts like numbers or geometrical designs.
Objects are defined by creating xe2x80x9cclassesxe2x80x9d which are not objects themselves, but which act as templates that instruct the computer how to construct the actual object. A class may, for example, specify the number and type of data variables and the steps involved in the methods which manipulate the object""s data. When an object-oriented program is compiled, the class code is compiled into the program, but no objects exist. Therefore, none of the variables or data structures in the compiled program exist or have any memory allotted to them. An object is actually created by the program at runtime by means of a special function called a xe2x80x9cconstructorxe2x80x9d which uses the corresponding class definition and additional information, such as arguments provided during object creation, to construct the object. Likewise, objects can be destroyed by a special function called a xe2x80x9cdestructorxe2x80x9d or can be destroyed by special programs called xe2x80x9cgarbage collectorsxe2x80x9d when no longer needed. Objects may be used by using their data and invoking their methods. When an object is created at runtime, memory is allotted and data structures are created.
The principle benefits of object-oriented programming techniques arise out of three basic principles; encapsulation, polymorphism and inheritance. Specifically, objects can be designed to hide, or encapsulate, all, or a portion of, the internal data structure and the internal methods. More particularly, during program design, a program developer can define objects in which all or some of the attributes and all or some of the related methods are considered xe2x80x9cprivatexe2x80x9d or for use only by the object itself. Other data or methods can be declared xe2x80x9cpublicxe2x80x9d or available for use by other programs. Access to the private variables by other programs can be controlled by defining public methods for an object which access the object""s private data. The public methods form a controlled and consistent interface between the private data and the xe2x80x9coutsidexe2x80x9d world. Any attempt to write program code which directly accesses the private variables causes the compiler to generate an error during program compilation which error stops the compilation process and prevents the program from being run.
Polymorphism is a concept which allows objects and functions which have the same overall format, but which work with different data, to function differently in order to produce consistent results. For example, an addition function may be defined as variable A plus variable B (A+B) and this same format can be used whether the A and B are numbers, characters or dollars and cents. However, the actual program code which performs the addition may differ widely depending on the type of variables that comprise A and B. Polymorphism allows three separate function definitions to be written, one for each type of variable (numbers, characters and dollars). After the functions have been defined, a program can later refer to the addition function by its common format (A+B) and, at runtime, the program will determine which of the three functions is actually called by examining the variable types. Polymorphism allows similar functions which produce analogous results to be xe2x80x9cgroupedxe2x80x9d in the program source code to produce a more logical and clear program flow.
The third principle which underlies object-oriented programming is inheritance, which allows program developers to easily reuse pre-existing programs and to avoid creating software from scratch. The principle of inheritance allows a software developer to declare classes, and the objects which are later created from them, as related. Specifically, classes may be designated as subclasses of other base classes. A subclass xe2x80x9cinheritsxe2x80x9d and has access to all of the public functions of its base classes just as if these functions appeared in the subclass. Alternatively, a subclass can override some or all of its inherited methods or may modify some or all of its inherited methods merely by defining a new method with the same form. Overriding or modification does not alter the method in the base class, but merely modifies the use of the method in the subclass. The creation of a new subclass which has some of the functionality, with selective modification, of another class allows software developers to easily customize existing code to meet their particular needs.
Object-Oriented Programming languages include C++ and Java, as well as other languages. Each language has an express or implied xe2x80x9cobject model.xe2x80x9d Generally speaking, an object model is a unifying set of rules that describe object structure, object life cycle, and inter-object communication. Object structure relates to the physical layout of objects in memory, while object life cycle refers to how applications create and destroy objects. Inter-object communication refers to protocols by which objects communicate with one another. Object models are useful in contexts where all objects in a given system need to conform to a given protocol governing these parameters. Most object-oriented and object-based languages, including the Java programming language, do not specify true object models, but merely specify syntax and semantics of a basic object implementation without specifying the actual rules that unify object systems. Some object-oriented languages also incorporate the notion of xe2x80x9ccomponentsxe2x80x9d which are self-contained objects that perform a specified function or procedure. Components have a pre-defined interface that conforms to the object model of the underlying language and generally conform to a xe2x80x9ccomponent modelxe2x80x9d associated with the language.
In addition in order to using more efficient languages to reduce programming time, programming techniques have also been improved. Initially, program were written by typing lines of program statements. In the case of OOP programs, time was spent entering information with complicated syntax which was relatively standard from object to object. For example, for each constructor or method, a programmer normally wrote lines of code to marshal the data for each parameter of the method or constructor. The programmer then had to write a code line to call the method. In the case of methods, the programmer had to write code lines to capture and store the result of the method call. Finally, the programmer had to write code to deal with exceptions that occurred during the method call. This was tedious and led to a proliferation of typographical and spelling errors which increased the debugging time.
However, recently, xe2x80x9cvisual buildersxe2x80x9d are increasingly being used to expedite programming. A visual builder allows programs to be written with the help of a Graphical User Interface (GUI) and, under control of the GUI, the builder manipulates the xe2x80x9cstandardxe2x80x9d code portions of the class and allow program developers to create class code by specifying the class properties and writing code for the class methods. Each class can be represented by an icon on the GUI. Generally, when an icon representing code for a class is selected, the class properties and class method names are retrieved and listed in a predetermined part of the display. The property values and method names can then be modified without actually examining and modifying the underlying code. In many cases it is possible to further select a method name to view the actual program code associated with the method.
The visual builder generates the actual class code for the object from the user specified properties and methods, including the code for marshaling data and handling results and exceptions. Many visual builders also contain predefined classes with predefined interfaces, which classes are called components. The components have properties and methods that can be customized or used to derive other component. These predefined components are generally represented as icons on a xe2x80x9cpalettexe2x80x9d, to which new components can be added. A programmer using the visual builder manipulates these components on the screen, or xe2x80x9cin the active windowxe2x80x9d or xe2x80x9cworkspacexe2x80x9d, to create new component.
In some visual builders, the properties and methods of components can also be linked by the programmer using the visual builder interface to create a unique program. As a result, it is not necessary, to some degree, for a visual programmer to spend as much time entering code and debugging minor mistakes as a typical software developer who must enter the code text directly.
Examples of visual builders are disclosed in U.S. Pat. No. 5,546,519 to Berry, which illustrates describes a system and method for the visual programming of iterator link objects using a standard visual builder, whereby the user need not know the programming language itself. Properties of objects are also editable, usually via pull-down menus, and new objects can be added to the visual builder palette, primarily as a function of the visual builder itself.
In U.S. Pat. No. 5,642,511 to Chow et. al., a system and method are described for implementing an improved visual builder which allows a program developer to manipulate a hierarchical tree used to represent an OOP program. In the Chow patent a xe2x80x9cproxyxe2x80x9d tree comprised of proxy objects is built by using a visual builder to copy and edit user selected objects, thereby creating a new program.
Visual builders are attractive because they help to reduce programming time. When component classes are created with a visual builder, it is desirable to test them within the visual builder interface or application. This would increase programmer efficiency and reduce the time it takes to develop code using a visual builder, because it would allow the component class code to be tested before objects were created from it and incorporated into applications. However, current visual builders do not allow components to be tested in this efficient manner for several reasons. For example, current visual builders cannot specify at runtime parameters which are often required by methods in the component. Instead, conventional visual builders require objects to actually be built from the class code and then the objects are tested. If the object works, it is assumed that the class code is correct. Once a class is tested and shown to operate correctly, then it can be safely incorporated in to a visual builder palette for use by programmers.
Therefore, a need exists for a method and apparatus for compiling and testing newly created component classes within the visual builder interface. A need exists for visually creating, editing and testing composite component classes, including visually editing properties and associating methods among component classes within the composite component class.
In accordance with one illustrative embodiment, a proxy component is created for each method, including constructors, in the component class code, which proxy component encapsulates the parameters of that method. In particular, parameters associated with a method are represented by properties of the proxy component created for that method. When each proxy component is displayed on the GUI of a conventional visual builder, its properties, and consequently, the parameters of the underlying method, are visually editable and can be bound visually to other component properties using, for example, a mechanism in a conventional visual builder which links objects. Exceptions which occur during operation of the method are treated as events and can be visually passed to other components. Therefore, a program can be visually constructed and parameterized for runtime operation.
In order to actually run components to test them in accordance with one embodiment, an inventive universal transport application provides a mechanism for manipulating local or remote objects in a xe2x80x9ccomponent-orientedxe2x80x9d manner directly from the visual builder. Essentially, the universal transport API is an object request broker which is controlled by proxy components and can be used without manually wrapping the underlying classes. The universal transport application can be used whether the underlying classes are local or remote and even if the classes do not conform to either the Remote Method Invocation (RMI) or the Common Object Request Broker Architecture (CORBA) specifications.